Wire the prompt editors into the review, extend the chain, and cover three thin areas - #134

Three of the least-covered areas, chosen for being reachable headlessly rather
than for being easy: each test drives the real widget with the modal dialogs
stubbed to whatever the user would have answered.

- The prthinker settings form: every field gets an editor, keys are echoed as
  dots, the backend and platform come from the supported lists, a stored value
  that is no longer on offer does not silently persist, and a save that fails
  leaves the window open rather than looking like it worked.
- The project tree's right-click actions: where a new item lands, refusing to
  overwrite an existing name, an open editor tab following a rename and closing
  with a delete, absolute against tree-relative path copying, and an OSError
  surfacing as a dialog rather than a traceback.
- The plugin and "Run with" menus: entries built from a supplied registry rather
  than whatever is installed, sorted and labelled by suffix, and the suffix
  mismatch that must warn instead of running the wrong compiler.

64 new tests, 937 total. Coverage 57% to 60%: the settings dialog reaches 100%,
editor_main 20% to 58%, menu 40% to 54%.

judge, judge_single_review and step_by_step_analysis were never imported: 217
lines of prompt that no chain ran and the editor did not even offer. They are
now steps in the chain, placed where their inputs exist.

  first_summary -> first_code_review -> judge_single_review
                -> linter -> code_smell_detector -> step_by_step_analysis
                -> total_summary -> judge

judge_single_review scores the review written just before it. step_by_step
walks each lint message and code smell through cause, impact and fix. judge
scores the finished summary with the findings it was meant to cover in hand,
which needed the total summary's answer kept rather than discarded.

Eight steps would have taken the match statement in _run_templates past the
complexity the project allows, so the wiring moves into cot_chain: two tables
saying where each answer is stored and which placeholder each fills. The order
is now a dependency order a test can check, rather than a sequence held in one
function's local variables.

Two behaviours change with it. A step whose input never ran quotes an empty
section instead of the literal word "None". A step that fails is still shown to
the user but no longer stored, so a later step cannot quote "could not send"
back to the model as if it were a review.

The prompt editors wrote .md files that nothing ever read: a review always sent
the template compiled into the source tree, so editing a prompt changed nothing.
The editor existed to adjust what a review asks, and did not.

prompt_store resolves a prompt to the file the editor writes, falling back to the
built-in constant. The files move from the working directory to
~/.pybreeze/prompts/, beside the SSH known hosts and the prthinker settings, so
the prompts someone has written are the same whichever folder the IDE was
started from; both editors now show that path. Nothing is orphaned by the move --
no prompt file existed anywhere yet.

A missing, empty or unreadable file falls back to the built-in, and so does an
edited prompt naming a placeholder the chain cannot fill: a KeyError there would
take down a review the user has no way to debug from the UI. Reading a prompt no
longer creates the directory, so a session that only looks at built-ins leaves
nothing behind.

The skill selector in the send window was connected to nothing at all -- picking
a template did not load it. It now loads the chosen prompt, edited version first.

The CoT and Skill editors were the same 157 lines each, differing only in which
templates they list and which language keys label them. Loading the selected
file, creating it from its built-in template, saving, and picking up an external
edit were all written out twice, so a fix to one of them was a fix to half the
editors.

PromptEditorWidget holds that behaviour; each editor is now the file list, the
templates and a PromptEditorLabels of its language keys. 314 lines become 233.

The keys stay literal strings at the subclass rather than being built from a
prefix, because the parity test finds keys by reading the source for
language_word_dict.get("..."). A prefix would have slipped past it, so the keys
are declared plainly and a new test walks the two label sets directly -- a
renamed key is still caught rather than showing up as a blank button.